Protection of confidential information may be more difficult than ever before because of the proliferation of networked computing devices. Comprehensive protection of information stored in computer-readable form should include identity management, authorization/authentication, data integrity assurance, proper logging/auditing, i.e., to ensure chain of custody, and a guarantee of confidentiality. Data encryption is part of most protection regimes. Data encryption is known for protecting both data in-flight and data at rest. Data in-flight encryption is especially valuable for data that leaves the relatively safer and more secure “behind the firewall” environment. Data in-flight has received significant attention, and there are many commercially available products. Data at rest has received less attention. Recently, there have been some highly publicized incidents in which data at-rest in the form of backups on tapes have been lost or otherwise compromised. This publicity has lead to increased demand for encryption of data at rest on tape. However, the threat to data at rest may actually be greater when it is stored on disk than tape because the on-disk data is more current, and therefore more valuable. Further, the data at rest on-disk is more likely to be accessible via a network, and a greater number of individuals are likely to have access to the data, whether rightfully or not. The problem may even be worse than it generally appears because data breaches tend to be under-reported because of potential embarrassment and bad publicity.
There are commercially available behind-the-server encryption devices for disk-based storage which connect via Fibre Channel (“FC”) devices and are capable of encrypting data streams at wire speed with negligible latency. These FC based devices perform a relatively simple transport function, utilizing information such as the identity of the host from which the request has come and LUN IDs provided by the file server. For the sake of clarity, it should be recognized that there are two levels of LUN IDs in FC. FC itself has an 8-byte LUN ID (a logical entity). There is also a 3-bit LUN ID within the SCSI command description block (“CDB”), which is a holdover from a time when the only option was to have up to 7 devices on a SCSI chain. These IDs combine to identify the logical entity precisely. In particular, the FC devices use the FC LUN ID (8 bytes, including the WWN of the host), and may also use the 3 bit SCSI LUN ID within the CDB, to identify uniquely the intended LUN. The encryption capabilities supported are on a per-LUN basis. In NAS systems, filesystems are often striped across LUNs, and even more commonly, are built atop multiple LUNs. As a result, a NAS system utilizing current FC devices can cause multiple file systems to have their respective data encrypted with the same key. This commingling causes a security vulnerability because, for example, the owner of a file in one file system could deduce the key used to encrypt that file, and then use that key to decrypt files in other filesystems, i.e., files owned by others. Where the same key is used for the entire LUN, the person could gain access to any data in that LUN.
One solution to the commingling problem is a full proxy server which operates in front of the existing file server. The proxy server compares the pathname of the component being accessed with the pathname of the top of the container, i.e., the share or export. However, even this simple context support comes at a significant price in terms of performance because two additional trips through the entire protocol stack are required in addition to the processing overhead required for the encryption itself.